[% setvar title Overview: Perl OO should I<not> be fundamentally changed. %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>Overview: Perl OO should <i>not</i> be fundamentally changed.</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Damian Conway &lt;<a href='mailto:damian@conway.org'>damian@conway.org</a>&gt;
  Date: 21 Aug 2000
  Last Modified: 18 Sep 2000
  Mailing List: <a href='mailto:perl6-language-objects@perl.org'>perl6-language-objects@perl.org</a>
  Number: 137
  Version: 2
  Status: Frozen</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>This RFC proposes that the OO model and mechanisms present in
Perl 5 <i>not</i> be changed significantly in Perl 6. It provides
an overview of a suite of forthcoming RFC proposals that will
provide the features, convenience, and safety that are missing
from Perl 5, without compromising the essential flexibility of
the existing Perl OO model.</p>
<a name='EXECUTIVE SUMMARY'></a><h1>EXECUTIVE SUMMARY</h1>
<p>It ain't broken. Don't fix it.</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>Perl's current OO model has a number of well-known deficiencies:
lack of (easy) encapsulation, poor support for hierarchical method
calls (especially constructors and destructors), limited (single)
dispatch mechanism, poor compile-time checking. More fundamentally,
many people find that setting up reliable OO class hierarchies requires
too much low-level coding.</p>
<p>But these very deficiencies are also Perl's great strength, compared
to other, more restrictive, OO languages. The non-prescriptive,
non-proscriptive nature of Perl's OO model makes it possible to
construct am enormous range of OO systems within the one language:
from archetype-based classless OO (Class::Classless), to formal
Design-By-Contract models (Class::Contract). Effectively, Perl's
OO mechanism spans the range of metaphors from Self to Eiffel --
an astonishing achievement.</p>
<p>It is proposed that modules like Class::Classless, Class::Struct,
and Class::Contract continue to be the preferred method of constraining
and simplifying the creation of Perl classes, and that a better
range of such modules (at very least, Class::Contract) be included in
the standard distribution.</p>
<p>To deal with the existing deficiencies without losing the remarkable
power, I intend to propose the following extensions to OO Perl:</p>
<ul>
<li><a name='A private keyword that lexically scopes hash keys to the current package, and allows hashes to contain two or more identically named (but differently scoped) entries. This would solve the problem of encapsulation in OO Perl for the vast majority of (predominantly hash-based) class structures.'></a>A <code>private</code> keyword that lexically scopes hash keys to the current
package, and allows hashes to contain two or more identically named (but
differently scoped) entries. This would solve the problem of
encapsulation in OO Perl for the vast majority of (predominantly
hash-based) class structures.</li>
<li><a name='A new special subroutine name -- SETUP -- to separate construction from initialization. SETUP methods would be automatically -- and hierarchically -- called whenever an object is created.'></a>A new special subroutine name -- <code>SETUP</code> -- to separate construction
from initialization. <code>SETUP</code> methods would be automatically -- and
hierarchically -- called whenever an object is created.</li>
<li><a name='Changes to the semantics of bless so that, after associating an object with a class, the class's SETUP methods are automatically called on the object. An additional trailing @ parameter for bless, to allow arguments to be passed to SETUP methods.'></a>Changes to the semantics of <code>bless</code> so that, after associating an
object with a class, the class's <code>SETUP</code> methods are automatically
called on the object. An additional trailing <code>@</code> parameter for
<code>bless</code>, to allow arguments to be passed to <code>SETUP</code> methods.</li>
<li><a name='Changes to the semantics of DESTROY, so that all inherited destructors are, by default, automatically called when an object is destroyed.'></a>Changes to the semantics of DESTROY, so that all inherited destructors
are, by default, automatically called when an object is destroyed.</li>
<li><a name='Pre- and post-condition specifiers, which associate code blocks with particular subroutine/method names. These blocks would be automatically called before and after the subroutine/method of the same name, and trigger an exception on failure. For methods, pre- and post-conditions would be inherited and called hierarchically (with disjunctive short-circuiting, in the case of post-conditions).'></a>Pre- and post-condition specifiers, which associate code blocks with
particular subroutine/method names. These blocks would be automatically
called before and after the subroutine/method of the same name, and
trigger an exception on failure. For methods, pre- and post-conditions
would be inherited and called hierarchically (with disjunctive
short-circuiting, in the case of post-conditions).</li>
<li><a name='Class invariant specifiers, which associate code blocks with a particular package/class. These blocks would be called automatically after the the execution of subroutine/method of the same name, and trigger an exception on failure. For methods, invariants would be inherited and called hierarchically.'></a>Class invariant specifiers, which associate code blocks with a particular
package/class. These blocks would be called automatically after the the
execution of subroutine/method of the same name, and trigger an
exception on failure. For methods, invariants would be inherited and
called hierarchically.</li>
<li><a name='Optional, configurable, multiple dispatch of methods, based upon typed parameters.'></a>Optional, configurable, multiple dispatch of methods, based upon typed
parameters.</li>
<li><a name='A NEXT pseudo-class, enabling resumption of the dispatch search from within an invoked method, as well as the &quot;rejection&quot; of invocation (e.g. by an AUTOLOAD).'></a>A <code>NEXT</code> pseudo-class, enabling resumption of the dispatch search
from within an invoked method, as well as the &quot;rejection&quot; of invocation
(e.g. by an <code>AUTOLOAD</code>).</li>
<li><a name='Constraints on lexical variables such that my Dog $spot can only be assigned a value $v if $v-isa('Dog')&gt;.'></a>Constraints on lexical variables such that <code>my Dog $spot</code> can only
be assigned a value $v if <code>$v-</code>isa('Dog')&gt;.</li>
<li><a name='An optional constraint (use strict 'objvars'?), making it a fatal error to store a object reference in a non-typed lexical.'></a>An optional constraint (<code>use strict 'objvars'</code>?), making it a fatal
error to store a object reference in a non-typed lexical.</li>
<li><a name='A new pragma -- delegation -- that would modify the dispatch mechanism to automatically delegate specific method calls to specified attributes of an object.'></a>A new pragma -- <code>delegation</code> -- that would modify the dispatch
mechanism to automatically delegate specific method calls to specified
attributes of an object.</li>
</ul>
<p>Collectively these extensions would significantly reduce the amount
of code required to construct safe OO classes, whilst leaving
available the existing &quot;unconstrained&quot; OO model where it might
be needed.</p>
<p>There will also be one additional -- and far more radical -- proposal
that does not form part of the above suite. It would greatly enhance the
reusability of OO Perl software, but at the cost of existing
flexibility and greater migration effort.</p>
<p>The proposal is:</p>
<ul>
<li><a name='That in Perl 6, only hashes (and perhaps pseudohashes) may be blessed.'></a>That in Perl 6, only hashes (and perhaps pseudohashes) may be blessed.</li>
</ul>
<p>This would result in no loss of functionality, since any other data type
that was previously blessed as an object could instead be made a
single attribute of a blessed hash. However, combined with the proposed
<code>private</code> keyword and <code>use delegation</code> pragma, this proposal would
ensure that it was always possible to inherit from an existing class
without detailed knowledge of its implementation.</p>
<a name='NOTE ON TERMINOLOGY'></a><h1>NOTE ON TERMINOLOGY</h1>
<p>Several of the above proposals refer to &quot;hierarchical calling&quot;. This means
that if a method is invoked, all methods of the same name in all base
classes are <i>also</i> called. The order in which this occurs depends on the
nature of the method: <code>SETUP</code>s would be called &quot;top-down&quot; (most-ancestral first),
whereas <code>DESTROY</code>s, <code>pre</code>s, and <code>post</code>s would be called &quot;bottom-up&quot;
(most-immediate ancestor first).</p>
<a name='MIGRATION ISSUES'></a><h1>MIGRATION ISSUES</h1>
<p>Virtually none. That's the point. :-)</p>
<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
<p>See Migration issues.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>Conway, D., &quot;Object Oriented Perl&quot;, Manning, 2000.</p>
<p>Meyer, B., &quot;Eiffel: The Language&quot;, Prentice-Hall, 1992.</p>
<p><a href='http://www.sun.com/research/self/index.html' target='_blank'>www.sun.com</a></p>
<p>RFC 8: The AUTOLOAD subroutine should be able to decline a request</p>
<p>RFC 28: Perl should stay Perl.</p>
<p>RFC 92: Extensible Meta-Object Protocol -- Method Search</p>
<p>RFC 95: Object Classes</p>
<p>RFC 126: Ensuring Perl's object-oriented future</p>
<p>RFC 128: Subroutines: Extend subroutine contexts to include name parameters and lazy arguments</p>
<p>Numerous forthcoming proposals</p>
</div>
